|
|
|
|
|
|
|
Figure 10.1.
The latest version of the Samsona Bank Teller System use-case model. |
|
|
|
|
|
|
|
|
Depicting the extends relationship between use cases is similar to depicting the relationship between an interface class and an implementation class. When one use case extends another, you can say that that use case implements the stated behavior of the use case in a specialized way. |
|
|
|
| | For a bank, say you have a use case Open a Checking Account. Now, the bank has a use case for opening a special bank account product, Open a Basic Personal Checking Account. If the Open a Checking Account use case represents the basic stated behavior of all checking account use cases, the use case Open a Basic Personal Checking Account implements the former one but is specialized for the Basic Personal Checking product. As you can see, this form of use case relationship can become complicated and is, therefore, unpopular with newcomers to object technology. |
|
|
|
|
|
The content of each of your use cases now is as follows: |
|
|
|
 |
|
|
|
|
Open an Account |
|
|
|
|
|
|
|
|
A new or existing customer can open an account. If the customer is a new customer with no previous accounts and has the minimum required balance, he's free to apply for an account. The bank teller must be able to capture the customer's demographic information, such as full name, address, birth date, Social Security number, home and |
|
|
|
|
|
